1. Field of Invention
The present invention relates generally to network systems. More particularly, the present invention relates to efficiently detecting trace identifier mismatches using a system which includes hardware and software.
2. Description of the Related Art
The demand for data communication services is growing at an explosive rate. Much of the increased demand is due to the fact that more residential and business computer users are becoming connected to the Internet. To address the demand for data communication services, the use of optical networks, such as a synchronous digital hierarchy (SDH) network or a synchronous optical network (SONET), is becoming more prevalent. SONET and SDH networks are examples of time division multiplexed (TDM) networks. TDM networks generally allocate single lines to be used amongst multiple users, or customers of data communication services. The single lines may each be divided into slots of time during which each user has access to the single lines.
A network typically includes multiple nodes which are in communication over data lines. As shown in FIG. 1, nodes 100 are in communication with each other through lines 104 such that a string 108 that is sent from node 100a to node 100d passes through nodes 110b, 100c. String 108 is a transmission, and may be of a format such as a SONET format or an SDH format. As will be understood by those skilled in the art, string 108 may include overhead bytes that contain trace identifier strings. Trace identifier strings are unique sequences of bytes that effectively identify a transmitting source. Different formats of sequences of bytes are substantially defined by architectural standards.
In general, J0, J1, and J2 overhead bytes contain trace identifier strings. A J0 overhead byte may be used to monitor a regenerator sections level. A J1 overhead byte may be used as a path trace monitoring string to monitor a SONET path level, or an SDH VC-4 higher-order path as well as an SDH VC-3 high-order and lower-order paths, as appropriate. A J2 overhead byte may be used to monitor a SONET virtual tunnel level or SDH VC-2, VC12, or VC11 lower-order paths.
Conventionally, a transmission such as a SONET or an SDH transmission that includes overhead bytes which contain trace identifier strings are sent from a transmitting source to a receiving source, e.g., from a node such as node 100a to an intermediate receiving node such as node 100b or to a destination node such as node 100d. The receiving source is typically arranged to perform trace monitoring. Some receiving sources use hardware both to capture trace identifier strings and to perform trace monitoring, while other receiving sources use hardware to capture trace identifier strings and software to perform trace monitoring. As shown in FIG. 2a, a transmitter 200 may be in communication with a receiver 204 across a link 208. Link 208 typically carries transmissions from one up to approximately 192 high order circuits. Receiver 204 includes hardware 212 which both captures trace identifier strings and performs trace monitoring substantially sequentially on each of the circuits associated with link 208. Alternatively, FIG. 2b shows a transmitter 220 that is in communication across a link 228 with a receiver 224 that includes both a hardware component 232 and a software component 236. Hardware component 232 is arranged to capture trace identifier strings, and software 236 is arranged to perform trace monitoring substantially sequentially on each circuit that is associated with link 208.
When a trace identifier mismatch is detected, a notification of the trace identifier mismatch is usually provided, as for example to a network administrator, so that issues which caused a trace identifier mismatch may be resolved. FIG. 3a is a process flow diagram which illustrates the steps associated with detecting and providing notification of a trace identifier mismatch using a system in which trace monitoring is performed using hardware, e.g., the system of FIG. 2a. A process 260 of performing string analysis on a string associated with a given circuit begins at step 264 in which hardware captures a string. Typically, the string that is captured is a 64-byte string from SONET and a 16-byte string for SDH, which are stored in memory included in the hardware. Once a string is captured, the hardware compares the captured string to an expected string in step 268. It should be appreciated that an expected string is generally stored in memory included in the hardware after the expected string is provided, as for example by an owner of the line card of which the hardware is a part.
A determination is made in step 272 as to whether the captured string matches the expected string. That is, it is determined whether the captured string includes an expected byte sequence. If it is determined that the captured string matches the expected string, then process flow returns to step 264 in which the hardware captures another string. Alternatively, if it is determined that the captured string does not match the expected string, then the indication is that there is a trace identifier mismatch. As such, in step 276, the hardware signals a central processing unit, e.g., a central processing unit associated with the line card, that a trace identifier mismatch was detected. Then, in step 280, software that is in communication with the central processing unit signals that a mismatch was detected. Once the software signals, as for example to a network administrator, that a mismatch was detected, the process of performing string analysis returns to step 264 in which hardware captures a string. Signaling that a mismatch was detected allows steps to be taken to correct issues which resulted in a trace identifier mismatch.
With reference to FIG. 3b, the steps associated with performing string analysis using a combination of hardware and software, e.g., using the system of FIG. 2b, will be described. A process 300 of performing string analysis begins at step 304 in which hardware captures a string, e.g., a 64-byte string. Once the hardware captures the string, software then reads the captured string from the hardware in step 308. Then, in step 312, the software compares the captures string to an expected string, and it is determined in step 316 whether the captured string matches the expected string.
If the determination in step 316 is that the captured string matches the expected string, then there is no trace identifier mismatch, and process flow returns to step 304 in which the hardware captures another string. Alternatively, if it is determined that the captured string does not match the expected string, then the software signals that a mismatch was detected, and process flow returns to step 304 in which the hardware captures another string.
The monitoring of trace identifier strings generally enables verifications to be made that a circuit is properly connected, and that transmissions along a given circuit are occurring as expected. Monitoring trace identifier strings generally requires substantial resources and significant data processing. For each circuit or path, monitoring a trace string requires capturing a continuous string of bytes, determining the format of the string, identifying the start of the string, comparing the trace string to an expected string, and effectively raising an alarm if the trace string does not match an expected string.
As the number of circuits that are to be monitored increases, the hardware memory requirements needed in a trace identifier mismatch detection system increases. When a relatively large number of circuits are to be monitored, it may not be possible to provide enough memory to support the monitoring of the relatively large number of circuits. Further, as the number of circuits increases, the average time to detect a trace mismatch increases, as the trace monitoring is such that circuits are monitored in a sequential manner. By way of example, since each circuit of path is generally visited three times before a defect or a trace mismatch is detected, in a system with 192 circuits, 576 circuits must effectively be monitored before a trace mismatch for each circuit may be detected. Hence, the time between when a trace mismatch arises and when the trace mismatch is detected may be relatively significant. As a result, within a system in which specifications are such that a trace mismatch is effectively required to be detected within a certain amount of time, it may not be possible to support all the circuits and still meet minimum acceptable levels of system performance.
Therefore, what is needed is a trace mismatch detection system that operates efficiently and is suitable for supporting a relatively high number of circuits. That is, what is desired is a trace mismatch detection system which is scalable to support both a relatively low number of circuits and a relatively high number of circuits, does not require a significant amount of memory, and has relatively fast detection and processing times.